【レポート】Amazon Aurora はこう使え！貴方にだけ便利な使い方教えます！ #AWSSummit

AWS Summit Online Japan 2020

#レポート

#Amazon Aurora

#AWS

豊崎隆

2020.09.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ご機嫌いかがでしょうか、豊崎です。2020年9月8日から30日まで開催されるAWS Summit Onlineを自宅から拝聴しています。

本記事で取りあげるセッションは、「Amazon Aurora はこう使え！貴方にだけ便利な使い方教えます！」です。

セッション情報

スピーカー

アマゾンウェブサービスジャパン株式会社技術統括本部インターネットメディアソリューション部ソリューションアーキテクト桑野章弘

概要

Amazon Aurora は、クラウド時代に Amazon が再設計した RDBMS です。また、システムを構築する上でデータベースを切り離すことはできません。 Aurora の事はご存知でも、Aurora では何ができるのか？何が良くなるのか？は知らない、という方は多いのではないでしょうか？このセッションでは Amazon Aurora の最新情報や、リリースされてから行ってきた機能追加などを紹介しながら、どう使うと Aurora を便利にお使いいただくことができるか、といった内容をユースケースをあわせて紹介していきます。

レポート

セッション対象者

Amazon Auroraをこれから使っていきたと思っている人
Amazon Auroraを触ったことはあるが詳細については知らない方

Amazon Auroraとは

Amazon Aurora

クラウド上で動作することに特化して構築されたMySQLとPstgreSQL互換のリレーショナルデータベース
1/10のコストで商用グレードのデータベースのパーフォーマンスと可用性
15リードレプリカまでスケールアウト可能
MySQLの5倍/PostgreSQLの3倍のスループット
自己修復型ストレージ
3AZにまたがり6つのデータコピー
ネットワークの隔離
RDSによる管理

クラウドをフル活用したアーキテクチャ

ストレージ部分の詳細

MySQLとのパフォーマンス比較（青線がAurora）

Aurora活用していますか？

Auroraに関するイメージは？
- 高速なMySQL/PostgreSQL互換DB？
- 管理が楽？
- ネットワークストレージがすごい？
Auroraはそれだけではない！
- 運用やアーキテクチャの簡素化をするための機能を使いこなそう！

もっとAuroraを活用する方法

簡単に負荷テストをしたい
- 大規模リリース前には実環境のデータに可能な限り近いデータで負荷テストを行いたいが同じ環境を作るのは大変！
- 課題
  - 精度の高い負荷テストをお行うために本番データに近いデータが欲しい
  - 本番データの容量が大きい場合バックアップ・リストアに時間がかかる
  - 精度の高いデータを生成するのが大変
  - 負荷試験の実施のたびにデータのリストアが必要
- 従来の負荷試験環境DBの構築
  - １：負荷試験環境構築
  - ２：確保するリソースの確認
  - ３：開発環境のイメージ（バックアップ）から負荷試験環境を作成
  - ４：負荷試験環境用のデータベースを再作成
  - ５：アプリケーション開発者が負荷試験環境を使用可能に
- Auroraによる負荷試験環境DBの構築
  - １：負荷試験環境構築
  - ~~２：確保するリソースの確認~~
  - ~~３：開発環境のイメージ（バックアップ）から負荷試験環境を作成~~
    - Database Cloningを使用して開発環境のプライマリから開発環境を作成（インフラ）
  - ~~４：負荷試験環境用のデータベースを再作成~~
  - ５：アプリケーション開発者が負荷試験環境を使用可能に
- 環境作成は短時間で実施可能
- データ量もPrimary＋αのデータ量で構築可能

オペミスをしてしまった時
- 例えばその１
  - 誤った削除をしてしまった→早急にデータを復旧しなければならない
  - 誤ったアップデートをしてしまった→できるだけオペミス直前に戻りたい
- 従来の対応例
  - １：取得していたスナップショットバックアップのリストア
  - ２：別途取得しているBinlogを適用しオペミス直前まで戻す
  - 愚直にやると非常に手間がかかる
- Auroraでの対応例
  - ~~１：取得していたスナップショットバックアップのリストア~~
  - ~~２：別途取得しているBinlogを適用しオペミス直前まで戻す~~
    - Backtrackを使うことで即時オペミス直前まで戻すことが可能
    - 注意点
      - クラスタ全体でしか戻せない
      - Binlogなどストレージ以外のものについては戻らない

- 例えばその２
  - アプリのバグで想定していないデリートが走っている→復旧したかの確認を行う
- 従来の対応例
  - １：取得していたスナップショットバックアップのリストア
  - ２：アプリケーション側でログと付き合わせてデータ復旧
  - ３：新しいデータベースにサルベージする
- Auroraでの対応例
  - ~~１：取得していたスナップショットバックアップのリストア~~
  - ~~２：アプリケーション側でログと付き合わせてデータ復旧~~
  - ~~３：新しいデータベースにサルベージする~~
    - ストリーミングバックアップからポイントリンタイムリカバリ
    - S3へ継続的且つ自動的に増分バックアップされている
    - 1-35日の保持期間を指定可能
    - 5分前からバックアップの保持期間までの任意の位置に秒単位で復元可能

簡単にパフォーマンス監視をしたい
- 従来の対応方法
  - 監視サーバに監視ソフトウェアをいれる
  - チェックして閾値を割ったら通知するように設定
- Auroraでの対応例
  - ~~監視サーバに監視ソフトウェアをいれる~~
  - ~~チェックして閾値を割ったら通知するように設定~~
    - Performance InsightsやCloudWatchで監視可能
    - 各種ログをAmazon CloudWatch Logsで管理可能

Auroraに入っているデータを元にビックデータ分析をしたい
- ビックデータ分析時の課題
  - データ分析がわへ出力する場合にデータベースに負荷がかかる
  - データが多すぎるため定期的に取得して整形、データ分析側へ出力するのは非常に労力がかかる
- 分析環境へのデータ取り込み（従来の対応方法）
  - １：データをダンプする
  - ２：ダンプデータをバッチサーバへ配置
  - ３：バッチサーバで必要なETL処理を行う
  - ４：データウェアハウス/データレイクへインポート
- 分析環境へのデータ取り込み（Aurora）
  - Aurora上でINTO OUTFILE S3を使用することでSELECTの結果を直接S3へエクスポート可能
  - （必要に応じてAWS GlueでETL）
  - 各種サービスからS3へクエリ可能
- 分析環境へのデータ取り込み（Aurora&RDS）
  - 定期的に取得されたSnapshotからS3へエクスポート
  - （必要に応じてAWS GlueでETL）
  - 各種サービスからS3へクエリ可能